Your experience, Perry, is one that illustrates some of what *I* think is wrong with the way CERT handles things. I'm certainly not going to defend it, especially after I've complained about it myself (and for the same incident -- I pissed off several people inside the CERT at the time because of my comments on the incident, and pointed out your comments on the net as prime example). Heck, a lot of times, and that time in particular, they have failed to share similar information with other FIRST teams let alone outside "clients"! I will observe, however, that your site was not broken into at the time. CERT is principally an aid to sites that have already been broken into. Your experience (and others like them) doesn't mean that CERT is useless...it simply means that the usefulness is limited to admins of systems already compromised. Even that isn't completely fair, because they do have some documents and classes to help novices get a better handle on general security. However, CERT has largely become a "help clean up after the fact" organization because of their disclosure policy. I will also observe that if you were running Sun systems and had a big institutional committment to Sun, then the person you should have contacted was Mark Graff (the listed FIRST contact for Sun). In situations such as the one you describe, the vendor is best able to say if a particular vulnerability is in place given a particular OS release and a particular set of patches (folks at CERT and other places have neither source code nor do they have versions of every OS available; when they say "can't tell you" it may actually mean "unable because we have no idea"). If the vendor doesn't respond, then you, as a customer, should bitch loudly (or your lawyers should :-). ------ As I said before, this is getting away from what "bugtraq" is intended to address. We should not continue the discussion here. Besides, I don't think there is any disagreements over the basic points: * Not all response teams are the same * FIRST is not CERT * CERT is not "evil incarnate", nor are they useless. They simply aren't as useful as the image some people have (had) * The general community is somewhat safer with groups like CERT than without * Response teams could do a better job in some ill-defined ways. * Our #1 problem is the people who try to break into our systems, not the people who are trying to help (misguided or otherwise) I'm going to have a captive audience of members of the repsonse teams in July (assuming they come to my talk :-). I've been asked to give the kickoff/keynote address at the FIRST workshop on incident response. I'm going to talk about how to do a better job. I have some specific things in mind already, but I'd be interested in hearing from people about how response teams (in general) could do a better job. However, before you respond, keep the following in mind about response teams: 1) They don't have much funding 2) Their personnel are usually overworked already 3) Non-vendor teams usually don't have source code 4) They often don't have versions of all the systems their clients are running so they can test fixes & bugs 5) They can be sued for giving out advice that is incorrect and causes damage 6) They can be sued for giving out source code that is covered under non-disclosure and license (even if that same code is present in something like the BSD NET2 code). 7) Most of the bad guys and "wannabes" have the same access to announcements as users 8) It is not always the case that vulnerabilities and bugs are known to all the bad guys prior to announcement, and response team members have no way of knowing for sure for a particular case. 9) A large number of system admins have probably under 1 year experience with Unix -- announcements and fixes have to work for them without additional hand-holding 10) Really expert users will not be happy with any level of detail, no matter how much is given. 11) Some vendors are slow to develop fixes, and few will respond faster (or at all) with wide disclosure. If you, or anyone else on bugtraq has any suggestions or ideas, I'd love to hear them. Please reply to me *personally* however, and not to the whole list. --spaf